feat: attachment subcommands (list, upload, download) - #58

The attachment subcommands need both directions: upload encodes a --name
path so percent-escapes never leak into the UI, and download decodes a
stored name for --flat. No behavior change.

Refs #9

info accepted a numeric id or a markdown file; read accepted a numeric id
or a page URL. Neither was a superset, so what a page argument meant
depended on which command you gave it to.

internal/pageref accepts all three, and both commands now use it. The
change is additive on each side -- info gains URLs, read gains files -- so
no existing invocation changes meaning. A file is stat'd before the numeric
check, so "123.md" resolves as a file.

The attachment subcommands and #37/#44 take page arguments too, which is
what makes one resolver worth extracting now.

Refs #9

List a page's attachments as aligned NAME/SIZE/VER/TYPE/SOURCE columns, or
one JSON result per attachment so `.results[] | .filename` works directly.

SOURCE is the markdown image path an attachment was published from, which
makes the command a view of what a publish will and will not touch --
including the orphans left behind by the attachment-name encoding change.

A dash in SOURCE means no source path was recorded, which covers both a
hand-uploaded attachment and one published before markfluence recorded
them; the managed field in --json tells those apart. Verified against a
live page carrying one of each.

No download_url is emitted: on the site URL it fails under a scoped token,
and on the request base it would leak the gateway host into reader-facing
output.

Refs #9

Upload or replace attachments on a page, reusing the checksum bookkeeping
create/update already use so uploading by hand and publishing agree on what
is current. --dry-run reuses PlanAttachments; --force uploads regardless,
which is how a user repairs an attachment whose stored bytes drifted while
its recorded checksum still matches.

--name takes a path rather than a stored name, and markfluence encodes it,
so `--name assets/x.png` produces the attachment an image written as
![](assets/x.png) resolves to without the user typing an escape. The
recorded path= is always the decode of the stored name: were they allowed
to disagree, a later publish would upload a second attachment under the
name it computes while a restoring download put this one somewhere the
markdown never references.

planAttachments now records the existing id even for a skip, so a forced
upload replaces in place instead of re-deriving it.

Verified against a live page: created, then skipped unchanged, then --force
bumped the version 1 -> 2.

Refs #9

Write a page's attachments to disk. An attachment markfluence published is
restored to the markdown image path recorded in its comment, so the
downloaded tree matches what the page references and previews locally in
GitHub or VSCode; --flat writes stored names instead. With no NAME every
attachment is downloaded; an existing file is skipped unless --force, and a
NAME the page doesn't have fails that item rather than the run.

Restoration reads the recorded path and never decodes the stored name.
There is no way to tell a hand-uploaded "a%2Fb.png" from one markfluence
published, so decoding by default would scatter a literally-named file into
a/b.png; an attachment with no recorded path keeps its stored name.

destPath is the only place server data becomes a filesystem path, so it
clamps to --dest. ".." cannot simply be refused -- an image in a directory
above its page is a supported layout -- so the resolved path is compared
against the root, and escaping is an error rather than a silent clip:
attachment comments are controlled by anyone who can edit the page. This
takes over the clamp 018 deferred to #37.

Verified against a live page: managed attachments restored to
assets/markfluence-test.png and probe/notes.txt, the underscore-era orphan
written under its stored name, bytes byte-identical to the source, --flat
and --force as specified, and a missing name exiting 1.

Refs #9

README gets a usage section per command, plus a note up front that every
command naming a page takes an id, a URL, or a .md file -- previously true
of neither info nor read alone. The --json notes gain the new status verbs
and spell out what "one result per target" means per command, since the
target is the attachment for the attachment-* commands.

CLAUDE.md gets the three commands, internal/pageref, and the client's
attachment expand, offset pagination, and download path -- including the
warning never to add a CheckRedirect that forwards headers. Also corrects
the root bullet's stale "four subcommands" and the cmd/ list, which had
never picked up read.

Closes #9

ARG was defensible when info and read each accepted a different, loosely
specified thing. Since pageref unified them, all five commands take exactly
one thing -- a page reference -- and the placeholder should say so. It read
worst in attachment-upload ARG FILE..., where ARG drew no contrast at all.

Also disambiguates NAME in attachment-list's help, which is a column there
but a positional argument in attachment-download, and fills in the .md form
in read's README prose, which it gained in the pageref refactor.

No behavior change; positional arguments are unaffected.